According to the definition in SUN's Java™ (a program language) Servlet Tutorial, servlets are Java modules that extend request/response-oriented servers, such as Java-enabled web servers. For example, a servlet might be responsible for taking data in an HTML order-entry form (get request from requestor's browser) and applying business logic used to update a company's order database (build the response dynamically and send back to the requester). Servlets are to servers what applets are to browsers. Unlike applets, however, servlets have no graphical user interface.
Actually, a servlet is an abstract concept, and it may be mapped to implementations of different kinds of protocols. It includes not only HTTP (Hypertext Transfer Protocol) servlet for processing HTTP request/response but also other format servlets such as SIP (Session Initiation Protocol) servlet. Since HTTP servlet is so common and most of the servlets are actually HTTP servlet, people almost forget about other possible formats of servlet.
FIG. 1 is a schematic view showing the working process of a typical HTTP servlet. In FIG. 1, after completing inputting in a page form (not shown) on a browser of client 100, a user sends an HTTP request to an HTTP Server (a common Web Application Server) 120 with servlets installed, the servlet container (not shown) in the HTTP server 120 maps the HTTP message to the corresponding Servlets therein, and then invokes the servlet. The servlet searches the database 130 for the corresponding data, builds a response message to the HTTP request, and sent the HTTP response message back to the client 100 to be browsed and used by the user. This is the working manner of a typical HTTP servlet.
Next, the servlet container in prior art will be described in detail with reference to FIG. 2. FIG. 2 shows the internal operational principle of a server and the architecture of a servlet container. In FIG. 2, server class 200 represents a server connected with a client through web (not shown) (all kinds of webs such as internet, etc.), which sends the HTTP message received from the client to the connector 204 through service class 202. Here, for example, the service class is the 8080 port, which is a physical connection between the server class 200 and the connector 204. At the connector 204, the HTTP message (physical data packet) sent from the service class 202 is converted into logical commands to form a HTTP request, and the HTTP request is sent to the servlet container 220. Moreover, the connector 204 also converts the HTTP response received from the servlet container 220 into a HTTP message, and sends the HTTP message to the client through service class 202 and server class 200. The servlet container 220 connected with connector 204 works in the upper layer of the Java Virtual Machine (JVM). A Java virtual machine can be viewed as a server with server functions, and can be provided with a plurality of servlet containers 220.
In the order from lower layer to upper layer, a servlet container 220 contains a container engine 206 for starting up and maintaining the work of the whole servlet container 220; a virtual host 208 working in the upper layer of the container engine 206 for simulating a plurality of hosts; a context 210 working in the upper layer of the virtual host 208 and being responsible for managing a concrete application running in the virtual host; a wrapper 216 working in the upper layer of the context 210, for managing a certain servlet composing a application; and an HTTP servlet 212 working in the top layer of the servlet container 220 and being the most elementary unit to complete a certain work or task.
When the Java virtual machine is started up, it will use the service class 202 to create a HTTP connector 204 and a container engine 206. A container engine 206 may consist of and manage many virtual hosts 208. A host 208 may consist of and manage many contexts 210. A context 210 may consist of and manage many wrappers 216. And a wrapper 216 will actually instantiate and process the received HTTP request by using servlets 212.
When an HTTP request is sent to the servlet container 220, corresponding servlets 212 are generally invoked only by the servlet container 220 through context 210. In addition, a servlet 212 can invoke other servlets (not shown) in the same servlet container 220, or be invoked by other servlets (not shown) in the same servlet container 220. There is no other way to invoke a servlet 212 itself. For example, invoking a servlet using a normal Java class is invalid. Also from the inherent property of servlet, after a servlet is initiated due to an incoming request, it can invoke other Java codes, but there is no way for the servlet 212 to directly and automatically get an event from outside of the container 220.
As described above, different servlets 212 within the same context 210 may share some states and events. But, besides the HTTP request, there is no way for a normal servlet 212 to simulate a servlet from outside of a context 210. For example, it is impossible for servlets on two different Java virtual machines to collaborate, such as sharing state information or send events to each other. Even within the same Java virtual machine, if two servlets are located in two different servlet containers, it is still impossible for these two servlets to collaborate. It is a limitation of the normal servlet in prior art.
It is mentioned in the above that the “servlet” is just a concept, and the HTTP servlet is only one of various possible formats. Now, with another important protocol, i.e. “SIP (Session Initiation Protocol)”, a new kind of servlet, i.e. “SIP servlet” has been defined in the Java standardization organization. A HTTP servlet is mainly used to process web request, while a SIP servlet is mainly used to process VoIP (Voice over IP) application. A SIP servlet inherits the common features of general HTTP servlet object, but there exist great differences between them, as listed in Table 1.
TABLE 1ModelMappingInvokingHTTPRequest/ResponseUse servlet “path” toNormallyServletmap a HTTP request toinvoked bya servlet that processend userthe requestusing abrowserSIPCan use request/Use predefinedNormally byServletresponse model and“mapping rule” to mapa invokedcreate new requests ona SIP request to a SIPSIP clientits own initiative, orservletforward the receivedrequests to one ormore target address
It can be seen from Table 1 that a HTTP servlet can only perform one to one process of request/response, i.e. it can only generate one response to one HTTP request, and sends the response back to the client. And a SIP servlet not only can generate requests on its own initiative, but also can generate a plurality of branch requests on the basis of one request, which will be sent to different servers or Java virtual machines, and generates corresponding response so as to accomplish more complicated tasks. It can be seen that more complicated functions (such as multiparty interactive conference) of web application services, etc. can be implemented by applying HTTP servlet and SIP servlet simultaneously, thereby the user is provided with more facilitated services.
When it is necessary to implement inter-invoke of a HTTP servlet and a SIP servlet or other kinds of servlets so as to accomplish specific tasks, we refer to it as converged application service. As the popularization process of network is deepened and developed, the capability of convergently processing different protocols including HTTP and SIP appears especially important in the converged application service.
In the converged application service, servlets are used as the programming model for a specific task and different protocols (such as HTTP protocol and SIP protocol), wherein a plurality of protocols may be used instead of one single protocol such as HTTP. This means that different servlet containers are needed. One typical example of such converged application service is so-called “Web Scheduled Conference System” in which HTTP protocol is used to input scheduling information for the conference and SIP protocol is used to initiate calls from conference server to the individuals participating the conference. However, in the prior art, the servlet model only cares about HTTP protocol, and only those servlets that belong to the same (HTTP) servlet container can collaborate with each other. The current solution to solve the above problem is only to modify the HTTP servlet container.
FIG. 3 is a schematic view showing the mode for implementing converged application service in the prior art. As shown in FIG. 3, in the prior art, in order to implement the converged application service, HTTP servlet and SIP servlet must be built in the same context respectively, and the converged application service provider must provide both HTTP servlet and SIP servlet. But it is very difficult in the prior art. Since they rely on the supports of different protocols, and a HTTP servlet provider may not be so skillful at SIP while a SIP servlet provider may not be so skillful at HTTP, rewriting the primary codes of current servlet container in an application server to support SIP protocol cost a lot of time and funds. Further, if the service provider collectively constructs the HTTP servlet and the SIP servlet from different venders upon the same context, there will be disputes on the aspect of intellectual property. Further, even if the problem is solved in the above manner, there will be difficulties when more protocols are needed to support the converged application service.